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Abstract 


The Chorus software is designed to investigate near-term, tactical conflict and loss 
of separation detection and resolution concepts for air traffic management. This 
software is currently being used in two different problem domains: en-route self- 
separation and sense and avoid for unmanned aircraft systems. This paper describes 
the core resolution algorithms that are part of Chorus. The combination of several 
features of the Chorus program distinguishes this software from other approaches 
to conflict and loss of separation resolution. First, the program stores a history of 
state information over time which enables it to handle communication dropouts and 
take advantage of previous input data. Second, the underlying conflict algorithms 
find resolutions that solve the most urgent conflict, but also seek to prevent sec- 
ondary conflicts with the other aircraft. Third, if the program is run on multiple 
aircraft, and the two aircraft maneuver at the same time, the result will be implicitly 
coordinated. This implicit coordination property is established by ensuring that a 
resolution produced by Chorus will comply with a mathematically-defined criteria 
whose correctness has been formally verified. Fourth, the program produces both 
instantaneous solutions and kinematic solutions, which are based on simple accel- 
eration models. Finally, the program provides resolutions for recovery from loss of 
separation. Different versions of this software are implemented as Java and C++ 
software programs, respectively. 
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1 Introduction 


The Chorus software is designed to investigate near-term, tactical conflict detec- 
tion and resolution concepts for air traffic management. This software is used in 
two air traffic domains, self-separation concepts [10,11] and unmanned aircraft sys- 
tems [3]. This paper describes the core conflict resolution algorithms that are part 
of Chorus. The combination of several features of the Chorus program distinguishes 
this software from other approaches to conflict resolution [4]. First, the program 
stores a history of state information over time which enables it to handle transient 
communication dropouts, and produce solutions that are sensitive to past inputs. 
Second, the underlying algorithms attempt to resolve both primary and secondary 
conflicts with all traffic aircraft. Primary confficts are those confiicts that exist on 
the current trajectory of the aircraft. Secondary confiicts are those confiicts which 
arise when an aircraft is maneuvering to resolve a primary conflict. Single resolu- 
tions to solve conflicts for multiple aircraft are known in the literature as a “1 to 
IV” solutions. Third, if the program is run on multiple aircraft, then the conflict 
resolutions between any two aircraft are implicitly coordinated. This implicit coor- 
dination property is established by ensuring that resolutions produced by Chorus 
will comply with a mathematically-defined criteria whose correctness has been for- 
mally verified [1,2, 6, 8]. Finally, the program was developed using a criteria theory 
that has undergone rigorous mathematical verification [1,2, 6, 8]. That is, the net 
effect of both aircraft maneuvering at the same time is beneficial and will avoid a 
loss of separation. Fourth, the program produces both instantaneous solutions and 
kinematic solutions, which are based on simple acceleration models. Finally, the 
program provides resolutions for recovery from loss of separation (LoS) in addition 
to conflicts. 

Chorus provides several different resolution algorithms that are useful for differ- 
ent applications. All of the Chorus algorithms use iterative search to find resolu- 
tions. The algorithms search over a range of potential solutions and methodically 
step through them to determine if they meet the desired properties. This is a change 
from our earlier work where we relied exclusively on analytical solutions [5]. A key 
advantage of the analytical solutions is that they are known to satisfy the desired 
properties based on an a-priori mathematical analysis and are often computation- 
ally more efficient. The advantage of the iterative approach used in Chorus is that 
the desired properties of the resolution can be much more complicated, but this 
comes at the cost of higher execution times. Although all of the Chorus resolution 
algorithms are iterative, in certain cases where an iterative solution is not found, an 
analytical solution from the ACCoRD CRSS 1 resolver is returned. The CRSS conflict 
resolution algorithm has been formally verified using the PVS theorem prover [9]. 

Resolution algorithms also differ in their design assumptions about how the air- 
craft will change from its current state (position and velocity) to the future resolution 
state. Chorus provides algorithms based on two different approaches: instantaneous 
and kinematic change. An instantaneous maneuver assumes the aircraft can in- 
stantly change from its current state to the target state. A kinematic solution 

x See [5] and other references at http://shemesh.larc.nasa.gov/fm/fm-atm-cdr.html 
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provides a simple model that uses a specified constant acceleration to achieve the 
target resolution state. 

Another important aspect of a conflict resolution algorithm is the goal of the 
algorithm, in particular, the safety property that the resolution algorithm is seeking 
to maintain. Chorus provides algorithms for two different goals: conflict avoidance 
and loss of separation recovery. Conflict avoidance is a safety goal that ensures that 
the aircraft will not be closer than given horizontal and vertical minimum distances, 
typically 5 nautical miles horizontally and 1000 feet vertically. The goal of a loss of 
separation algorithm is to find a resolution that quickly separates the aircraft and 
prevents a collision. The Chorus loss of separation algorithms produce resolutions 
that increase the distance at the closest point of approach and avoid nearly parallel 
final states. Note that this is a weaker property than conflict avoidance, but it can 
be applied when separation has already been lost. 

Sections in this paper describing the resolution algorithms are summarized in 
table 1. 



instantaneous 

kinematic 

conflict 

Section 5 

Section 6 

loss of separation (LoS) 

Section 7 

Section 7 


Table 1. Resolution Algorithms in Chorus 


The Chorus software has been released as open-source software and is available 
upon request. See http://shemesh.larc.nasa.gov/fm/fm-atm-codes.html for 
help in obtaining this software. 


2 Assumptions 

For the Chorus software to operate correctly, certain contextual assumptions must 
be satisfied. The most significant assumption is one of consistent shared knowledge. 
This is important for both conflict detection and for consistent criteria calculations. 
Specifically it is assumed that state information is accurate, within an error bound, 
and that any two aircraft in a conflict situation are using the same values. This 
can be achieved by having each aircraft send its state data according to a schedule 
based on a global clock. This ensures all aircraft use the same set of broadcasts 
as a basis for their calculations. In addition, the state data used for an aircraft’s 
internal calculations must be the same as the values that it broadcasts to other 
aircraft. This data is likely to be a discretized version of the native sensor data. 
For example, values could be read and timestamped on each second and broadcast 
before the next second. Calculations would then be based on data with timestamps 
that are at least a full second earlier than the current time. The time latency in 
the data can be compensated using standard linear projection. Fortunately, the 
mathematical criteria that serves as a basis of these algorithms calculates direction 
parameters that are insensitive to linear time projection. 
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Additionally, there is an assumption of a localized global awareness of traffic. 
That is, if aircraft A is considered to be the most urgent traffic by aircraft B, it is 
essential that A consider B to be its most urgent aircraft in order for there to be 
a guarantee of implicit coordination. There are subtle, multiple aircraft encounters 
where this property may not hold. For example, suppose that aircraft A is in conflict 
with aircraft B, but it is not in conflict with aircraft C. Further, suppose that aircraft 
B is in conflict with both C and A, but it loses separation with C before it loses 
separation with A. In this case, A views B as most urgent, while B views C as most 
urgent. Thus, aircraft A and aircraft B hold incompatible views about their most 
urgent aircraft. One subject of future work is to develop approaches to achieving 
compatible results for the most urgent aircraft even in complex scenarios such as 
these. It is important that this work take into consideration broadcast distances, 
which makes this problem even more difficult. 

The positions and velocities used in these algorithms are specified as 3-dimensional 
inertial Euclidean coordinates. Measurements in other coordinate frames, such as 
air-relative or geodetic frames, need to be projected into an Euclidean space as 
appropriate. The Chorus software automatically performs these projections if the 
input data is geodetic although we do not present the details of those projections 
in this paper. The East-North-Down projections used in Chorus are believed to be 
valid given the short distances and short time horizon of the Chorus algorithms. 


3 Notation 

The Chorus algorithms are captured in two versions written in an object-oriented 
style in both the Java and C++ programming languages, respectively. The Chorus 
algorithms are documented in this paper in a pseudocode that is neither Java nor 
C++. Instead, this pseudocode is a hybrid language incorporating features of both 
functional languages and object-oriented languages. The purpose of the pseudocode 
is to capture the major logic of the algorithms without the distracting details of a 
normal programming language. 

Common operations on sets or lists are assumed, so a list size function exists, and 
elements can be accessed by index, as indicated by array subscript notation list [x] . 
Similarly, standard mathematical vectors are available, Vect2 for a 2-dinrensional 
vector and Vect3 for a 3-dimensional vector. In addition, standard arithmetic on 
vectors is assumed, so for vectors u, v, and w and double a, v = u+w*a represents 
the assignments: 

v.x = u.x + w.x * a 

v.y = u.y + w.y * a 

v.z = u.z + w.z * a 

The pseudocode assumes the existence of an n-ary tuple data type, denoted by 
(xl , . . ,xn), which allow piecewise assignment, 

(xl, . . . , xn) = (yl, . . . , yn) 
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thus assigning xl the value yl, etc. In the Java and C++ source code, these opera- 
tions are often implemented as separate instance variables using appropriate accessor 
functions, and sometimes may be set as side effects as opposed to being returned 
explicitly in a function. 

Additionally, in order to simplify the presentation, pass-through parameters to 
longer function calls may be omitted. For example, 

criteria(s,vo,vi,vo’ ,minRelVs) 

will generally be represented as 

criteria! . . . , vo ’ , . . . ) 

Certain data that is expressed here as parameters may be implicitly passed as in- 
stance variables in the Java and C++ source code implementation. 

The definitions of the operators (+, -, *, /, ==, !=, etc.) are the definitions from 
Java or C++, without relying on exotic behavior such as overflow. We use AND and 
OR for the boolean connectives rather than && and I I used in Java and C++. The 
operator ~= is defined to mean “almost equals,” which means that the values are 
compared and if they are within a fixed floating point precision of each other, then 
they are considered to be equal. 

The loop statement syntax is taken from Java and C++ and, like these languages, 
it has the semantics of a for loop. 

for (initialization; test; increment) { . . . } 

Our notation for function definitions departs from Java/C++ syntax in that the 
return type of the function follows the parameters. For example, a function that 
computes the sine function would be declared as follows: 

sine(x) : double { . . . } 

Note that the types of the function parameters are not listed. We also allow an 
N-tuple return type: 

func(x,y,z) : (a,b) { ... } 

Here the function func has three parameters and returns two values with types: a 
and b. 

4 Common Variables and Functions 

The following variables are commonly used in the Chorus algorithms: 

so initial ownship position (s Q ) 
vo initial ownship velocity (v Q ) 
si initial traffic position (s;) 
vi initial traffic velocity (v;) 
s initial relative position (s) 
v initial relative velocity (v) 
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The algorithms use a vector library which provides the ability to algebraically 
manipulate vectors. The following are common functions: 


v . x 
v.y 
v . z 

vo ,trk() 
vo.gsO 

vo .vs() 
vo .mkTrk(trk) 

vo .mkGs (gs) 

vo .mkVs (vs) 


x component of vector v 
y component of vector v 
z component of vector v 
returns track component of velocity v Q 
returns ground speed component (2-D vector magni- 
tude) of velocity v Q 

returns vertical speed component of velocity v Q 
creates a 3-dinrensional velocity vector from v Q , where 
the track component is changed to trk 
creates a 3-dinrensional velocity vector from v Q , where 
the ground speed component is changed to gs 
creates a 3-dinrensional velocity vector from v Q , where 
the vertical speed component is changed to vs 


Additionally, the following function is used to define loss of separation between two 
aircraft: 

LoS (s , D , H) returns TRUE if the relative position s is in loss of sep- 
aration with respect to a protection zone with hori- 
zontal separation D and vertical separation H. 

This is defined as: 

s.x*s.x + s.y*s.y < D*D AND |s.z| < H 

The following are parameters that are assumed to be globally accessible and 
therefore these variables are not explicitly passed in the pseudocode: 


D 

H 

Tres 

aircraf tList 


minGs 

maxGs 

minVs 

maxVs 

checkSecondary 


minimum horizontal separation 
minimum vertical separation 
lookahead time for resolution 

list of all traffic aircraft. The ownship aircraft is not 
included in this list. The information for each air- 
craft in this list can be used to return its position 
and velocity (possibly extrapolated) at a given time, 
minimum ground speed allowed for ownship 
maximum ground speed allowed for ownship 
minimum vertical speed allowed for ownship 
maximum vertical speed allowed for ownship 
a boolean flag, where TRUE indicates aircraft other 
than the most urgent are considered 


5 Instantaneous Conflict Algorithms 

Chorus’ instantaneous conflict resolution algorithm attempts to find a resolution 
that is free of conflicts with all traffic aircraft. However, if a resolution cannot be 
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found that satisfies this property, then a resolution that is free of conflicts with 
only the most urgent aircraft is returned. How Chorus determines the aircraft that 
is most urgent is described in section 5.1. The algorithm proceeds in two steps. 
The first step finds a starting point for iteration (track angle, ground speed, and 
vertical speed) using the analytical solutions from the CRSS algorithm. The CRSS 
class implements the ACCoRD algorithms that have been formally verified 2 . The 
first step of the instantaneous conflict algorithm is as follows: 

resolution_i = CRSS.resolution(s,vo,vi,epsh,epsv) 
double trkO = 0 
double gsO = 0 
double vsO = 0 

if (CRSS . hasTrkOnly ( ) ) trkO = CRSS . trkOnly () 
if (CRSS .hasGsOnlyO ) gsO = CRSS.gsOnlyO 

if (CRSS .hasVsOnlyO ) vsO = CRSS.vsOnlyO 

The variable resolution_i is a status flag and it is used to indicate the nature of 
the resolution, for instance, “no conflict” or “loss of separation.” 

The second step of the algorithm seeks to avoid secondary conflicts by iteratively 
searching starting from the computed values trkO, gsO, and vsO. In all of the algo- 
rithms, the search direction (dir) is determined by the mathematical criteria. Before 
we discuss the instantaneous iterative resolution algorithms, we introduce three key 
functions: mostUrgent, nDetector and criteria in the next three sections. 

5.1 Most Urgent Aircraft 

An aircraft may have multiple conflicts with other aircraft on its current trajectory 
or be in loss of separation with more than one aircraft. In the conflict case, Chorus 
determines which aircraft has the most urgent conflict, that is, the conflict with 
the minimum time into loss of separation. The solution to this conflict serves as a 
starting point for solving any remaining primary or secondary conflicts. In the loss of 
separation case, the determination of most urgent is more subtle. The function that 
determines the most urgent conflict uses the following ranking (highest to lowest): 

1. Aircraft that are in loss of separation with the ownship that have convergent 
velocities, with the smallest cylindrical distance at time of closest approach [7] 
ranked first. 

2. Aircraft that are in loss of separation with the ownship having divergent ve- 
locities are ranked by the current horizontal distance. 

3. Aircraft that are in conflict with the ownship, with those that are closest (in 
time) to a loss of separation ranked higher. 

4. All other aircraft are ranked by current horizontal distance. 

2 See http : //shemesh . larc .nasa.gov/fm/fm-atm-cdr .html 
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Resolving conflicts with multiple aircraft is quite challenging. There are cases where 
the traffic density is so high that the ownship cannot find a suitable maneuver. Al- 
though resolution of all conflicts is desirable, it is not always possible and a com- 
promise must be made. In these cases, Chorus provides a resolution that solves the 
most urgent conflict and a flag is set to indicate unresolved conflicts. Furthermore, 
implicit coordination is only guaranteed with respect to the most urgent aircraft. 

5.2 Multiple Aircraft Conflict Probe: nDetector 

The nDetector function performs a conflict probe between the position and velocity 
of one aircraft (usually the ownship) and all other traffic aircraft. The iterative 
resolution algorithms described in this paper use the nDetector function to check 
potential resolutions, not just the current state of the ownship. Thus, the data sent 
to the nDetector function are possible ownship resolutions, not the actual ownship 
state data. This function requires the following parameters: 

so position of the ownship 

vo velocity vector of the ownship 

tOwn time when so and vo were collected 
mu index of the most urgent aircraft 

ignore index of aircraft that should be ignored. Use —1 to 
accept all aircraft 

The function is defined as follows: 

nDetector(so,vo,tOwn, mu, ignore) : boolean { 
for (j = 0; j < aircraf tList . size () ; j++) { 

T = Tres 

if (j == mu) T = MAXDOUBLE 
if (j != ignore) { 

(si,vi) = predLinear (aircraftList [j] ,t0wn) 

Vect3 s = so - si 

if (CDSS . conflict (s ,vo ,vi ,D ,H,T) ) return TRUE 

} 

> 

return FALSE 

> 

The function predLinear (ac , tOwn) estimates the position and velocity vectors for 
the traffic aircraft ac at time tOwn, using a linear extrapolation from the aircraft’s 
last position and velocity. The CDSS . conflict function performs the conflict de- 
tection and it is defined in Appendix B. If there is a conflict with any aircraft the 
nDetector function returns TRUE, otherwise it returns FALSE. The time parameter, 
T, indicates how far in the future conflicts should be checked. Setting T to MAXDOUBLE 
ensures resolutions will be sufficient to fully resolve the immediate conflict and any 
secondary conflicts with the most urgent aircraft. 
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The ignore value represents an aircraft to be ignored by the conflict detection. 
It is set to —1 (an invalid index) for primary detection (i.e. include all aircraft) and 
the index of the most urgent traffic for secondary conffict detection. 


5.3 Coordinated Maneuver Criteria: criteria 


Two resolution algorithms are said to be coordinated if they produce resolutions 
that solve the conflict when either one aircraft maneuvers or both aircraft manuever 
simultaneously. Coordination criteria is a boolean function that takes as inputs the 
state information for two aircraft. Criteria serves as a mathematical requirement 
for resolution algorithms such that if any two algorithms satisfy the criteria, then 
resolutions from those algorithms are coordinated. An elaborate mathematical the- 
ory of coordination criteria is presented in [2,6,8]. This theory provides important 
system-wide safety properties, which have been mathematically proven and proofs 
are contained in the references. 

In the Chorus resolution algorithms, criteria are used to set the search direction. 
Since the initial resolution (from the CRSS algorithm) is already coordinated, setting 
the iterative search direction in the coordinated direction ensures that an iterated 
solution is also coordinated. 

The function criteria requires the following parameters: 


s 

vo 
vi 
vo ’ 

minRelVs 


position of the ownship relative to the traffic aircraft 
velocity of the ownship aircraft 
velocity of the traffic aircraft 

velocity vector of the ownship to be checked against 
the criteria 

desired minimum relative exit vertical speed (used in 
LoS only) 


5.4 Track Algorithm 

The track algorithm depends upon both the nDetector conflict detector and the 
criteria function. The algorithm uses iteration on the variable trkDelta in the 
direction dir = ±1 and with an increment size step. At each iteration step a 
new track is computed: trkO+dir*trkDelta where trkO is the solution obtained 
from CRSS. The iteration is continued until the nDetector function indicates there 
is no conflict with any traffic aircraft and criteria indicates that the new vector 
meets the implicit coordination criteria, or until 180° have been searched. If a 
track solution cannot be found that solves the conflict with the most urgent aircraft 
(primary conflict) and also avoids secondary conflicts, then the resolution that only 
resolves the conflict with the most urgent aircraft, which is supplied by the CRSS 
function, is returned. 

inst_track(so,vo,tOwn,mu,trkO,dir,step) : (boolean, double) { 
hasTrk = FALSE 

for (trkDelta = 0; trkDelta < PI; trkDelta = trkDelta + step) { 


trk = trkO + dir * trkDelta 
vo’ = vo .mkTrk(trk) 

if ( NOT nDetector(so,vo ) ,tOwn,mu,-l) AND criteria( . . . , vo’ ,...)) { 
(hasTrk,trkOnly) = (TRUE, trk) 
break 

} 

> 

if ( NOT hasTrk) { 

(hasTrk , trkOnly) = (CRSS . hasTrkOnly ( ) , CRSS . trkOnly ( ) ) 

> 

return (hasTrk, trkOnly) 

> 


5.5 Ground Speed Algorithm 

The ground speed algorithm depends upon the nDetector conflict detector and the 
criteria function. The algorithm uses iteration on the variable gsDelta in the 
direction dir = ±1 and with an increment size step. At each iteration step a 
new ground speed is computed: gsO+dir*gsDelta, where gsO is the ground speed 
solution obtained from CRSS. The iteration is continued until the nDetector function 
indicates there is no conflict with any traffic aircraft and criteria indicates that 
the new vector meets the implicit coordination criteria, or until the ground speed 
exceeds the preset minGs , maxGs bounds. If no ground speed solution can be found 
that resolves the conflict with the most urgent aircraft (primary conflict) and that 
also avoids secondary conflicts, then a resolution that only resolves the conflict 
with the most urgent aircraft is returned. This resolution is computed by the CRSS 
function, 


inst_gs(so,vo,tOwn,mu,gsO,dir,step) : (boolean, double) { 
for (gsDelta =0; ; gsDelta = gsDelta + step) { 
nvGs = gsO + dir * gsDelta 
if (nvGs < minGs OR nvGs > maxGs ) break 
vo’ = vo .mkGs (nvGs) 

if ( NOT nDetector (so ,vo J ,t0wn,mu,-l) AND criteria( . . . , vo’,...)) { 
(hasGs,gsOnly) = (TRUE,nvGs) 
break 

> 

> 

if ( NOT hasGs) { 

(hasGs ,gs0nly) = (CRSS. hasGsOnly (), CRSS. gsOnlyO) 

> 

return (hasGs ,gs0nly) 

> 
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5.6 Vertical Speed Algorithm 

The vertical speed algorithm depends upon the nDetector conflict detector and 
the criteria function. The algorithm uses iteration on the variable vsDelta in 
the direction dir = ±1 and with an increment size step. At each iteration step a 
new track is computed: vsO+dir*vsDelta where vsO is the vertical speed solution 
obtained from CRSS. The iteration continues until the nDetector function indicates 
there is no conflict with any traffic aircraft and criteria indicates that the new 
vector meets the implicit coordination criteria, or until the vertical speed exceeds 
the preset minVs, maxVs bounds. If no vertical speed solution can be found that 
solves the primary conflict (with the most urgent aircraft) and also avoids secondary 
conflicts, then the resolution that only resolves the conflict with the most urgent 
aircraft (which is computed by the CRSS function) is returned. 

inst_vs(so,vo,tOwn,mu,vsO,dir,step) : (boolean, double) { 
for (vsDelta =0; ; vsDelta = vsDelta + step) { 
nVs = vsO + dir * vsDelta 
if ((nVs > maxVs) OR (nVs < minVs)) break 
vo’ = vo.mkVs(nVs) 

if ( NOT nDetector(so,vo’ ,t0wn,mu, -1) AND criteria( . . . , vo’,...)) { 
(hasVs , vsOnly) = (TRUE,nVs) 
break 

> 

> 

if ( NOT hasVs) { 

(hasVs ,vs0nly) = (CRSS. hasVsOnly (), CRSS. vsOnlyO) 

> 

return (hasVs .vsOnly) 

> 


6 Kinematic Conflict Algorithms 

The kinematic algorithms are more complex than the instantaneous algorithms, but 
provide better solutions because they take into consideration the fact that aircraft 
must maneuver over time to achieve the resolutions. Since the aircraft converge over 
time, the kinematic algorithms produce larger resolutions than the instantaneous 
algorithms. The difference between these resolutions will grow depending on how 
close the two aircraft are to each other, as shown in figure 1. In this figure, the 
original velocity is shown in red, the instantaneous solution is the straight resolution 
vector and the kinematic solution is the curved resolution vector. The kinematic 
solvers use models of aircraft dynamics with an assumed constant acceleration to 
project the positions of the ownship and traffic as the iteration as time progresses. 
The kinematic models used by these algorithms are defined in Appendix A. The 
determination of the most urgent conflict is described in section 5.1. 
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Figure 1. Kinematic and Instantaneous Trajectories for Conflict Resolution 

6.1 Future Conflict Detection: nDetectorConfFut 

The function nDetectorConfFut uses a kinematic projection of the future position 
of the aircraft and performs a conflict probe at the future point. 

This function performs conflict detection with respect to all aircraft on a future 
state of the ownship. The ownship future state is passed as a parameter. The traffic 
states are projected linearly using a relative time (delTm). It uses a list of traffic 
state data called aircraf tList. A function predLinear is used to interpolate the 
traffic data linearly to match the times of the ownship. It is expected that most 
of the time the interpolation will be unnecessary because the time stamps should 
match (except during communications dropouts). 

The function nDetectorConfFut returns a status per table 2 and has the fol- 
lowing parameters: 

soFut the future position of the ownship 
v’ the velocity vector to be checked for conflicts 
delTm the amount of time that the ownship is projected into 
the future (i.e., the time after tOwn when soFut is 
valid) 

mu the most urgent aircraft index 

tOwn timestamp for the current position and velocity (i.e., 
s 0 and v 0 ) 

Pseudocode for the function is: 

nDetectorConfFut (soFut ,v’ ,tOwn, delTm, mu) : int { 
int rtn = -1 

for (i = 0; i < aircraf tList . size () ; i++) { 

(si,vi) = predLinear (aircraf tList [i] ,t0wn) 

Vect3 s = soFut - si 
if (LoS(s,D,H) ) { 

if (i == mu) return 3 // LoS with primary 
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-1 

no conflict 

0 

secondary conflicts, no LoS, but is conflict free with most urgent aircraft 

1 

primary conflict 

2 

LoS with an aircraft that is not the most urgent one 

3 

LoS with most urgent aircraft 

Table 2. Values returned from nDetectorConf Fut 


else rtn = 2 

> 

Tresolve = Tres 

if (i == mu) Tresolve = MAX_VALUE 

boolean conf = CDSS . conflict (s ,v } ,vi ,D ,H,Tres) 

if (conf AND rtn < 0) rtn = 0 

if (i == mu AND conf AND rtn < 1) rtn = 1 


return rtn 

> 


6.2 Common Variables 


In addition to D, H, Tres, and aircraftList described in section 4, the following 
variables are assumed to exist in the kinematic calculations: 


maxBank 

gsAccel 

vsAccel 

minRelGs 

minRelVs 


maximum bank angle allowed for ownship 
ground speed acceleration allowed for ownship 
vertical speed acceleration allowed for ownship 
desired minimum relative speed for horizontal exit 
(used in LoS only) 

desired minimum relative speed for vertical exit (used 
in LoS only) 


6.3 Kinematic Track Algorithm 

The kinematic track algorithm iteratively searches for a solution that satisfies the 
criteria and is also free of secondary conflicts. It has the following parameters: 

so position of the ownship 
vo velocity of the ownship 
tOwn timestamp for the so,vo data 
mu index of the most urgent aircraft 
step the iteration step size 

Pseudocode for the function is: 

kinematicTrack(so,vo,tOwn,mu,step) : (boolean, double) { 
omega = turnRate(vo.gs() ,dir*maxBankAngle) 
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nDetKin = 0 
crit = TRUE 
nvTrk = 0 

Vect3 firstFound = ZERO 
hasTrk = FALSE 

for (trkDelta = 0; trkDelta < PI; trkDelta = trkDelta + step) { 
tm = dir * trkDelta / omega 
nvTrk = vo.trkO + dir * trkDelta 
(soAtTm,vo’) = turnOmega(so, vo, tm, omega) 
nDetKin = nDetectorConfFut(soAtTm,vo’ ,t0wn,tm,mu) 
crit = criteria!..., vo’,...) 

if (nDetKin == 0 AND crit AND firstFound == ZERO) firstFound = vo’ 
if (nDetKin >= 2) break // check for LoS 
if (nDetKin < 0 AND crit) { 

(hasTrk, trkOnly) = (TRUE, nvTrk) 
break 

} 

> 

if ( NOT hasTrk AND nDetKin < 2 AND firstFound != ZERO) { 

(hasTrk, trkOnly) = (TRUE,firstFound.trk()) 

> 

if ( NOT hasTrk AND nDetKin >= 2) { 
if (inf easibleUseFutureLos) { 

if (nDetKin == 3) { // entered LoS while iterating 

(hasTrk, trkOnly) = projectAndUseKinTrkLoS(tm,mu, step) 

} else { 

(hasTrk, trkOnly) = (TRUE, nvTrk) 

> 

} else { 

if (nDetKin == 3) { 

(hasTrk, trkOnly) = (CRSS.hasTrkOnlyO ,CRSS. trkOnly ()) 

> 

} 

> 

return (hasTrk, trkOnly) 

> 

A variable firstFound holds the first vector that is conflict-free with respect to 
the most urgent conflict. If a solution free of secondary conflicts is not found, 
the algorithm reverts to this solution. If the returned hasTrk value is FALSE, the 
returned trkOnly value is undefined. 

This algorithm contains a configuration flag, inf easibleUseFutureLos, which 
describes what should be done with the iteratively discovered solution that still 
has at least one loss of separation. If inf easibleUseFutureLos is FALSE then the 
solution from CRSS is returned. If inf easibleUseFutureLos is TRUE, then one of 
two possible solutions is returned. If the only solutions found continue to have 
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conflicts, then the algorithm projects the aircraft states into the future to exactly 
one half second after entry into LoS and computes a LoS resolution, using the 
function projectAndUseKinTrkLoS that is described below. Otherwise it returns a 
solution that is free of conflicts with the most urgent aircraft, but still has losses of 
separation with other aircraft. 

The projection into the future is accomplished by the function projectAndUse- 
KinTrkLoS which is defined as follows: 

projectAndUseKinTrkLoS(timeIntoLoS,mu,step) : (boolean, double) { 
si = aircraftList .get(mu) .position(timeIntoLoS + 0.5) 
vi = aircraftList .get(mu) . velocity (timelntoLoS + 0.5) 
soFut = so . linear (vo .timelntoLoS + 0.5) 
sFut = soFut - si 

if (sFut* (vo-vi) > 0 OR sFut . vect2() .norm() < D/2.0) { 
(hasTrk,trkOnly) = (TRUE,vo.trk()+dir*pi/4.0) 

} else { 

(hasTrk,trkOnly) = trackLoS(soFut,si,vo,vi,mu,TRUE,step) 

> 

> 

The variable timelntoLos is the computed relative time into LoS from the current 
position. The first if-branch is used for cases where the loss of separation entry point 
is the top or bottom of the protection zone, that is, there is already a horizontal 
loss of separation. The function trackLoS is defined in section 7.3. 

6.4 Kinematic Ground Speed Algorithm 

The kinematic ground speed algorithm iteratively searches for a solution that satis- 
fies the criteria and is also free of secondary conflicts. It has the following parameters: 

so position of the ownship 
vo velocity of the ownship 
tOwn timestamp for the so,vo data 
mu index of the most urgent aircraft 
step step size for search 

kinematicGroundSpeed(so,vo,tOwn,mu,step) : (boolean, double) { 
int nDetKin = 0 
Vect3 firstFound = ZERO 
hasGs = FALSE 

for (gsDelta = 0; TRUE; gsDelta = gsDelta + step) { 
double tm = gsDelta / gsAccel 
double nvoGs = vo.gsO + gsDir * gsDelta 
if ((nvoGs > maxGs) OR (nvoGs < 0)) break 
(soAtTm,vo’) = gsAccel(so,vo,tm, gsDir * gsAccel) 
nDetKin = nDetectorConfFut(soAtTm,vo’ ,t0wn,tm,mu) 
boolean crit = criteria(s , vo , vi , vo ’ , . . . ) 
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if (nDetKin == 0 AND crit AND firstFound == ZERO) firstFound = vo’ 
if (nDetKin >= 2) break // check for LoS 
if (nDetKin < 0 AND crit) { 

(hasGs ,gsOnly) = (TRUE,vo’) 
break 

} 

> 

if ( NOT hasGs AND nDetKin < 2 AND firstFound != ZERO) { 

(hasGs ,gsOnly) = (TRUE, firstFound. gs()) 

> 

if (nDetKin >= 2) { // some LoS or still in conflict 

if (inf easibleUseFutureLos) { 

si = aircraftList .get (mu) .position(timeIntoLoS + 0.5) 
vi = aircraftList . get (mu) . velocity (timelntoLoS + 0.5) 
soFut = so. linear (vo,timeIntoLoS + 0.5) 
siFut = si . linear (vi .timelntoLoS + 0.5) 

(hasGs ,gs0nly) = gsLoS (soFut, vo, siFut, vi, TRUE, step) 

} else { 

(hasGs ,gs0nly) = (CRSS.hasGsOnlyO ,CRSS.gsOnly()) 

} 

> 

return (hasGs, gsOnly) 

> 

The variable timelntoLos is the computed relative time into LoS from the current 
position. Just as in section 6.3, the inf easibleUseFutureLos flag is a configuration 
parameter that chooses between two different algorithms when the iterative solver 
cannot find a solution free of LoS for all aircraft. If the inf easibleUseFutureLos 
flag is FALSE then it reverts back to the CRSS solution. If the inf easibleUseFuture- 
Los flag is TRUE, then the algorithm projects the aircraft states into the future to 
exactly one half second after entry into LoS and computes a LoS resolution. The 
function gsLoS is defined in section 7.4. 

6.5 Kinematic Vertical Speed Algorithm 

The kinematic vertical speed algorithm iteratively searches for a solution that satis- 
fies the criteria and is also free of secondary conflicts. It has the following parameters 

so position of the ownship 
vo velocity of the ownship 
tOwn timestamp for the so,vo data 
mu index of the most urgent aircraft 
step step size for search 

kinematicVerticalSpeed(so,vo,tOwn,mu) : (boolean, double) { 

int nDetKin = 0 
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Vect3 firstFound = ZERO 

hasVs = FALSE 

for (vsDelta = 0; TRUE; vsDelta = vsDelta + step) { 
nVs = vo.vsQ + dir * vsDelta 
if ((nVs > maxVs) OR (nVs < minVs)) break 
tm = |nVs - vo.vs()| / vsAccel 
(soAtTm,vo ) ) = vsAccel(so,vo,tm,vsDir*vsAccel) 
nDetKin = nDetectorConfFut(soAtTm,vo’ ,t0wn,tm,mu) 
boolean crit = criteria(s , vo , vi , vo ’ , . . . ) 

if (nDetKin == 0 AND crit AND firstFound == ZERO) firstFound = vo’ 
if (nDetKin >= 2) break 
if (nDetKin < 0 AND crit) { 

(hasVs ,vs0nly) = (TRUE,nVs) 
break 

} 

> 

if ( NOT hasVs AND nDetKin < 2 AND firstFound != ZERO) { 

(hasVs ,vsOnly) = (TRUE, firstFound. vs()) 

> 

if (nDetKin >= 1) { // LoS with primary or secondary or still conflict 
if (inf easibleUseFutureLos) { 

si = aircraf tList . get (mu) .position(timeIntoLoS + 0.5) 
vi = aircraf tList . get (mu) . velocity (timelntoLoS + 0.5) 
soFut = so . linear (vo .timelntoLoS + 0.5) 
siFut = si . linear (vi , timelntoLoS + 0.5) 

(hasVs ,vs0nly) = vsLoS (soFut, vo, si, vi, TRUE, step, epsv) 

} else { 

(hasVs ,vs0nly) = (CRSS.hasVsOnlyO ,CRSS.vs0nly()) 

} 

> 

return (hasVs, vsOnly) 


The variable timelntoLos is the computed relative time into LoS from the current 
position. Just as in section 6.3, the inf easibleUseFutureLos flag is a configuration 
parameter that chooses between two different algorithms when the iterative solver 
cannot find a solution free of LoS for all aircraft. If the inf easibleUseFuture- 
Los flag is TRUE, the algorithm projects the aircraft states into the future to ex- 
actly one half second after entry into LoS and computes a LoS resolution. If the 
inf easibleUseFutureLos flag is FALSE, then it uses the CRSS solution. The func- 
tion vsLoS is defined in section 7.5. 
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-1 

no conflict 

1 

primary conflict 

2 

LoS with at least one aircraft that is not the most urgent aircraft 

3 

LoS with most urgent aircraft 

Table 3. Values returned from nDetectorLoSFut 


7 Loss of Separation Algorithms 

The criteria [8] provides a notion of correctness for loss of separation (LoS) algo- 
rithms that is based on the concept of repulsion. A solution is repulsive if the 
distance at the time of closest approach between the two aircraft is greater than the 
current distance. This is a fairly weak property, but the algorithms obtain good re- 
sults by seeking maximally repulsive solutions. That is, the iterations continue until 
the maximum vector that is repulsive is found. In the loss of separation case, the key 
factor is that the resolutions are implicitly coordinated. Therefore, the direction of 
the maneuver is far more important than the magnitude of the maneuvers. The LoS 
algorithms also seek to achieve a minimum relative exiting speed to avoid solutions 
that place the aircraft in nearly parallel trajectories at the end of the maneuvers. 

Each of the resolution algorithms presented below can produce either a instan- 
taneous solution or a kinematic solution, controlled by the parameter kinematic. 
Recall that an instantaneous solution is one where the aircraft is assumed to imme- 
diately achieve the maneuver whereas a kinematic solution is one where the aircraft 
must accelerate from its current position to achieve the resolution. 


7.1 Detect Future LoS: nDetectorLoSFut 


This function nDetectorLoSFut performs detection with respect to all aircraft (ex- 
cept a designated most urgent aircraft, which is ignored) on a future state. The 
ownship future state is passed as a parameter. The traffic states are projected lin- 
early using a relative time (delTm). The return values are listed in table 3. The 
parameters are: 


soFut future position of the ownship 
nv velocity vector to be checked for conflicts 
tOwn timestamp for so, vo data 

delTm the amount of time that the ownship is projected into 
the future (i.e. , the time after tOwn when soFut is 
valid) 

mu index of the most urgent aircraft 


The nDetectorLoSFut function is used in the LoS case and hence it does not 
check for conflicts with the LoS aircraft (i.e. mu). 


nDetectorLoSFut (soFut ,nv,tOwn, delTm, mu) : int { 
int rtn = -1 
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for (j = 0; j < aircraf tList . size () ; j++) { 
if (j != mu ) { 

(si,vi) = predLinear (aircraf tList [j] ,t0wn) 
si = si . linear (vi ,delTm) 

Vect3 s = soFut - si 
if (LoS (s , D , H) ) { 
rtn = 2 
break 

> 

boolean conf = CDSS . conflict (s ,nv,vi ,D,H,Tres) 
if (conf AND rtn == -1) rtn = 1 

} 

> 

return rtn 

> 

The function predLinear (tOwn) retrieves the position and velocity vectors for the 
traffic aircraft for time tOwn. The CDSS . conflict function performs the conflict de- 
tection (See appendix B). If there is a conflict with any aircraft the nDetectorLoSFut 
function returns TRUE, otherwise it returns FALSE. 

7.2 Determine Divergence: divergentHorizGt 

A pair are aircraft are said to be divergent if the separation at all future positions is 
greater than their current separation. The function divergentHorizGt determines 
if the current state between the two aircraft is divergent and the relative speed is 
greater than a specified minimum relative speed: 

divergentHorizGt (s , vo ,vi) : boolean { 

Vect2 v = vo - vi 

return s.dot(v) > 0 AND v.normO > minRelGs 

> 

7.3 Track LoS Algorithm 

The following pseudocode describes the iterative LoS track algorithm. It can pro- 
duce an instantaneous resolution or a kinematic one. The following parameters are 
used: 


SO 

ownship’s position 

vo 

ownship’s velocity 

si 

traffic aircraft’s position 

vi 

traffic aircraft’s velocity 

mu 

index of the aircraft to be resolved against, usually 
the most urgent aircraft 

kinematic 

flag which determines whether a kinematic or an in- 
stantaneous solution is desired 

step 

step size for search 
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The trackLos function is defined as follows: 


trackLoS(so, si, vo, vi, mu, kinematic, step) : (boolean, double) { 
vo’ = ZERO 

omega = turnRate(vo.gs() ,maxBank) 
boolean criteriaEverSatisf ied = FALSE 

for (trkDelta = step; trkDelta < PI/2; trkDelta = trkDelta + step) { 
nvoTrk = vo.trkO + trkDir * trkDelta 
tm = 0.0 

Vect3 soAtTm = so 
Vect3 siAtTm = si 
if (kinematic) { 

tm = trkDelta / omega 

soAtTm = turnOmega( so, vo,tm, trkDir * omega). first 
siAtTm = si . linear (vi ,tm) 

} 

sAtTm = soAtTm - siAtTm 

prevVo’ = vo’ 

vo’ = vo .mkTrk (nvoTrk) 

boolean divg = divergentHorizGt (sAtTm, vo’ ,vi) 
criteria = criteria(sAtTm,prevNvo , vi , vo ’ , . . . ) 
if (criteria) criteriaEverSatisf ied = TRUE 
if (checkSecondary) { 

nDetKin = nDetectorLoSFut (soAtTm, vo’ ,t0wn,tm,mu) 

} 

divgOrNotCrit = (divg OR NOT criteria) 
if (divgOrNotCrit) { 

if ( NOT criteria) lastSolution = prevVo’ 
else lastSolution = nvo 

if (f irstSolution == ZERO) f irstSolution = lastSolution 
if ( NOT criteria OR nDetKin <= 0 OR nDetKin >= 2) break 

> 

> 

if (f irstSolution == ZERO) { 
trkSolution = vo’ 

} else if (divgOrNotCrit AND nDetKin <= 0) { 
trkSolution = lastSolution 
} else { 

trkSolution = f irstSolution 

> 

hasTrk = (NOT (trkSolution = ZERO) AND criteriaEverSatisf ied) 
return (hasTrk, trkSolution. trk() ) 

> 

The repulsive criteria is usually satisfied in one direction up to a particular track 
value. This algorithm seeks to find the maximally repulsive track, but will stop 
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earlier if divergence is reached. There are some cases where there are no repulsive 
tracks available in the search direction. Therefore a flag criteriaEverSatisf ied 
informs hasTrk. If the non-criteria region is reached, there is no need to search 
further. When in the divergent region and the solution is free of all secondary 
conflicts, the search is stopped. Finally, if a secondary LoS occurs while searching, 
then the search is abandoned at that point. It is not clear whether it is better 
to return no track solution at this point, or just accept that a second LoS must 
occur and defer its resolution until later. The algorithm above does the latter. 
In the instantaneous (i.e. , non-kinematic) version, the value of sAtTm is set to s 
and remains constant throughout the for loop. The tests at the end cover several 
different cases. The first branch covers the case where the criteria is satisfied all 
the way through the loop and divergence is not reached. In this case the maximal 
search value is used. The second branch covers the case where divergence or not 
criteria was reached, and so lastSolution is used. The last branch occurs when 
a LoS occurs or no solution free of secondary conflicts is found (nDetKin > 0). In 
this case the f irstSolution value is used. 

The parameter minRelHoriz impacts the timeliness of the speed of exit from 
loss of separation. If this parameter is set to 0, then the algorithm merely seeks to 
achieve some positive relative speed. But if a larger value is specified, the algorithm 
seeks to achieve a higher relative exiting speed. This is likely to result in a larger 
maneuver. 

7.4 Ground Speed LoS Algorithm 

The following parameters are used by the ground speed LoS algorithm 


SO 

initial ownship position 

vo 

initial ownship velocity 

si 

initial traffic position 

vi 

initial traffic velocity 

mu 

the index of the aircraft to be resolved against, usually 
the most urgent aircraft 

kinematic 

flag which determines whether a kinematic or an in- 
stantaneous solution is desired 

step 

step size for search 


The following pseudo code describes the iterative ground speed algorithm: 

gsLoS(so, si, vo, vi, kinematic, step) : (boolean, double) { 
boolean divgOrNotCrit = FALSE 
boolean minSepOk = TRUE 
int nDetKin = 0 
Vect3 sAtTm = ZERO 
Vect3 vo’ = vo 
Vect3 prevVo’ = ZERO 
Vect3 f irstSolution = ZERO 
Vect3 lastSolution = ZERO 
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boolean criteriaEverSatisf ied = FALSE 

for (gsDelta = step; TRUE; gsDelta = gsDelta + step) { 
nvoGs = vo.gsO + gsDir * gsDelta 
if ((nvoGs > maxGs) OR (nvoGs < minGs)) break 
tm = 0.0 

Vect3 soAtTm = so 
Vect3 siAtTm = si 
if (kinematic) { 

tm = gsDelta / gsAccel 

soAtTm = gsAccel(so,vo,tm, gsDir * gsAccel) 
siAtTm = si . linear (vi ,tm) 

} 

sAtTm = soAtTm. Sub(siAtTm) 
prevVo’ = vo’ 
vo J = vo .mkGs (nvoGs) 
distBetw = sAtTm. vect2() .norm() 
if (distBetw < minSep) minSep = distBetw 
boolean divg = divergentHorizGt (sAtTm, vo’ ,vi) 
boolean criteria = criteria^AtTm.prevNvo.vi.vo’ , . . . ) 
if (criteria) criteriaEverSatisf ied = TRUE 
if (minSep <= gsLosDiscard) ) break 
divgOrNotCrit = (divg OR NOT criteria) 
if (divgOrNotCrit) { // save first solution 

if ( NOT criteria) lastSolution = prevVo’ 
else lastSolution = vo J 

if (f irstSolution == ZERO) f irstSolution = lastSolution 

> 

> 

if (checkSecondary) { 

nDetKin = nDetectorLoSFut(soAtTm,vo’ ,t0wn,tm,mu) 

> 

if (divgOrNotCrit) { 

if ( NOT criteria OR nDetKin <= 0 OR nDetKin >= 2) break 

> 

> 

if (f irstSolution == ZERO) { 
gsSolution = prevVo’ 

} else if (divgOrNotCrit AND nDetKin <= 0) { 
gsSolution = lastSolution 
} else { 

gsSolution = f irstSolution 

> 

boolean divgO = divergentHorizGt (sAtTm, vo J ,vi) 

double distAtTau = distAtTau(sAtTm,vo’ ,vi,TRUE) 

if ( NOT divgO AND distAtTau <= ChorusConfig. gsLosDiscard) { 
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hasGs = FALSE 
} else { 

hasGs = (NOT gsSolution . equals (ZERO) AND criteriaEverSatisf ied) 

> 

gsOnly = gsSolution. gs() 
return (hasGs, gsOnly) 

> 

In the instantaneous (i.e., non-kinematic) version, the value of sAtTm is set to s and 
remains constant throughout the for loop. The algorithm searches for a maximally 
repulsive solution that satisfies the criteria. If divergence is reached, then the search 
continues until a solution free of secondary conflicts is found (i.e. lastSolution). 
If the additional search is unfruitful, then the algorithm reverts back to the first 
solution that was divergent (i.e. f irstSolution). An additional test is applied 
that eliminates the ground speed solution when the projected distance at the closest 
point of approach (tau) is smaller than the parameter gsLosDiscard. The search 
is also short-circuited if a LoS occurs or the minimum separation becomes less than 
gsLosDiscard. There are some cases where there are no repulsive ground speeds 
available in the search direction. Therefore a flag criteriaEverSatisf ied informs 
hasGs. The case where the criteria is satisfied over the entire search range and 
divergence is not reached must also be covered. In this case, f irstSolution will 
still be ZERO. We use the next-to-last value searched, i.e., prevVo’ as the solution, 
because the last value may be outside of the (minGs ,maxGs) range. 

7.5 Vertical Speed LoS Algorithm 

The vertical LoS solver uses an inner collision region, a cylinder defined by a radius, 
caD, equal to 1000 ft and a half-height, caH, equal to 200 ft. The iterative search 
varies the vertical speed until there is no longer a conflict with this inner collision 
region and the relative exit speed is sufficiently large. The following parameters are 
used by the ground speed LoS algorithm 


SO 

initial ownship position 

VO 

initial ownship velocity 

si 

initial traffic position 

vi 

initial traffic velocity 

mu 

index of the aircraft to be resolved against, usually 
the most urgent aircraft 

kinematic 

flag which determines whether a kinematic or an in- 
stantaneous solution is desired 

step 

step size for search 

epsv 

The vertical epsilon value calculated by the criteria 


The vertical LoS algorithm is defined as follows: 

vsLoS(so, si, vo,vi, kinematic, step, epsv) : (boolean, double) { 
boolean solFound = FALSE 
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boolean innerConf = FALSE 
vsSolution = ZERO 
int nDetKin = 0 
Vect3 firstSoln = ZERO 

for (vsDelta = step/2; TRUE; vsDelta = vsDelta + step) { 
double nvoVs = vo.vs() + dir * vsDelta 
if ((nvoVs > maxVs) OR (nvoVs < minVs)) break 
double tm = 0.0 
Vect3 soAtTm = so 
Vect3 siAtTm = si 
if (kinematic) { 

tm = InvoVs-voVsl / vsAccel 

soAtTm = vsAccel(so ,vo,tm,dir * vsAccel) 

siAtTm = si . linear (vi ,tm) 

} 

Vect3 sAtTm = soAtTm - siAtTm 
vo’ = vo .mkVs (nvoVs) 
double alglnnerFactor =2.0 

boolean innerLos = CD3D . lossOf Sep(soAtTm, siAtTm, caD, 

alglnnerFactor * caH) 

if (innerLos) break 

innerConf = CD3D . cd3d( sAtTm, vo ’ , vi , caD , algInnerFactor*caH) 
solFound = (epsv* (nvoVs - vi.z) >= minRelVs AND NOT innerConf) 
if (checkSecondary) { 

nDetKin = nDetectorFut (soAtTm, vo ’ ,tm,mu) 
if (nDetKin == 2) { 
solFound = FALSE 
break 

> 

} 

if (solFound AND firstSoln == ZERO) firstSoln = vo’ 
solFound = (solFound AND nDetKin <= 0) 
if (solFound) break 

> 

if (solFound) { // solution free of secondary conflicts found 

vsSolution = vo’ 
hasVs = TRUE 
} else { 

if (firstSoln != ZERO) { 
vsSolution = firstSoln 
hasVs = TRUE 
} else { 

hasVs = FALSE 

> 
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return (hasVs,vsSolution.vs()) 

> 

As noted earlier, in the instantaneous (i.e. , non-kinematic) version, the value of 
sAtTm is set to s and remains constant throughout the for loop. The algorithm 
searches in the repulsive direction until there is no conflict with the inner collision 
region and the relative exit speed is sufficiently large. The vertical LoS criteria is 
simpler in that it is satisfied for all vertical speeds in the appropriate direction so 
a specific test is not needed (i.e. it is implicitly satisfied). The search continues 
beyond this point if there are secondary confficts in hope of reaching a solution 
free of secondary conflicts. If the additional search is unfruitful, then the algo- 
rithm reverts to the first solution that was found (i.e. firstSoln). The search 
is also short-circuited if a loss of separation occurs. The criteria variable epsv is 
used in the test epsv*(nvoVs - vi.z) >= minRelVs as a fast absolute value (i.e. 
InvoVs - vi.z I >= minRelVs). 

8 Summary 

Nine Chorus resolution algorithms have been defined that provide instantaneous 
and kinematic resolutions for both conflict and loss of separation situations. These 
algorithms have been documented using a pseudocode that clarifies the essential 
features of the algorithms. The rationale and key design decisions used in these 
algorithms are highlighted and discussed. 
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( S 0* S 0j) 


Figure Al. Kinematic Trajectory for Turns 


Appendix A 

Kinematic Trajectory Generation 


We formulate trajectory generation for turns as the computation of the future 
position and velocity of the aircraft, s (t) and v(f), given a constant turn rate (angular 
velocity), u>, and a time t. The initial position of the aircraft is s Q = ( s ox ,s oy ) and 
the initial velocity vector is v D = {v ox . v oy ). We let v be the speed of the aircraft, 
which equals |v 0 [, and 6 is the track angle of the initial velocity vector. In aircraft 
navigation, track angles and headings are measured from true north in the clockwise 
direction, thus 0 = atan(u ox , v oy ). Using these definitions, the initial velocity is 


v ox = v sin 6 
v oy = v cos 6 


(Al) 


By assumption, the aircraft’s new target velocity vector will be achieved by a 
constant angular velocity ui (i.e. ui = ^). This will result in time based velocity 
vector of v(t) = (v x (t),v y (t)), where 


v x (t) = v sin(# + u>t) 

Vy{t) = V COS (9 + Ldt) 


(A2) 


These relationships are shown in figure Al. 

Integrating, we obtain the trajectory of positions: 


s x (t) — s x (0) = cos(6> + u>t) | 0 = —[cos 0 — cos (6 + cut)] 

UJ UJ 

'U 1) 

s y (t ) — Sj/(0) = — sin(0 + ut) |o = [sin 6 — sin(0 + cut)] 

LO UJ 


(A3) 
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Collecting terms yields: 


V 

s x (t ) = Sa;(0) H — [cos 6 — COS (8 + Ujt)\ 

V ( A4 ) 

s y (t) = s y ( 0) [sin 8 — sin(# + cut)] 

UJ 

This is directly coded into the function turnOmega which takes the following pa- 
rameters: 

Vect3 sO starting position 
Vect3 vO initial velocity 
t time of turn 

omega rate of change of track, sign indicates direction 

The turnOmega function is defined: 

turnOmega (sO,vO,t, omega) : (Vect3, Vect3) { 
if (omega ~= 0) return (sO + vO * t,v0) 
v = vO.gsO 
theta = vO.trkO 

xT = sO.x + (v/omega) * (cos (theta) - cos(omega*t+theta) ) 
yT = sO.y - (v/omega) * (sin(theta) - sin(omega*t+theta) ) 
zT = sO.z + v0.z*t 
s’ = (xT,yT,zT) 

v’ = vO. mkTrk(vO. track () + omega * t) 
return (s’ ,v’ ) 

> 

Note, the symbol “~=” should be read as “almost equals,” which means that the 
values are compared and if they are within a fixed floating point precision of each 
other, then they are considered to be equal. 

Instead of a turn rate, u, turns are often specified with a bank angle. Thus, a 
means is needed to compute co from a bank angle, usually represented as </>. First, 
consider the equation for the turn radius of aircraft turning in level flight with bank 
angle 4>: 

v 2 

R = — — (A5) 

g tan cp 

where R is the turn radius, and g is gravitational acceleration. This formula relies 
on the assumption that the wing provides most of the lift force. For high bank 
angles, (j) > 45, where the body of the aircraft starts to provide lift, this equation 
is no longer valid. Continuing the development of an equation for uj, we use the 
relationship v = \lv\R to obtain 


g tan 

LO = 

V 


This equation is captured in the function turnRate. 


(A6) 
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turnRate(speed,bankAngle) : double { 
if (bankAngle ~= 0.0) return 0.0 
return g * tan (bankAngle) / speed 

> 


The function turnTime computes the time it takes to complete a turn given a 
ground speed, the magnitude of the track change and the maximum bank angle: 

turnTime(groundSpeed,deltaTrack, bankAngle) : double { 
omega = turnRate (groundSpeed, bankAngle) 
if (omega == 0.0) return MAXD0UBLE 
return I deltaTrack / omega | 

> 


The functions gsAccel and vsAccel are used to compute the trajectory for 
a constant ground speed acceleration and a constant vertical speed acceleration, 
respectively. 

gsAccel(so3,vo3,t,a) : (Vect3, Vect3) { 

Vect2 so = so3.vect2() 

Vect2 vo = vo3.vect2() 

Vect2 sK = so . Add(vo . Hat () . Seal (vo. norm () * t + 0.5 * a * t * t)) 

double nz = so3.z + vo3.z * t 

Vect3 nso = new Vect3(sK,nz) 

double nvoGs = vo3.gs() + a * t 

Vect3 nvo = vo3 .mkGs (nvoGs) 

return (nso, nvo) 

> 

vsAccel(so3,vo3,t,a) : (Vect3, Vect3) { 
nvoVs = vo3.vs() + a * t 
Vect3 nvo = vo3 .mkVs (nvoVs) 

Vect3 nso = (so3.x + t * vo3.x, 
so3.y + t * vo3.y, 

so3.z + vo3.z *t+0.5*a*t*t) 
return (nso, nvo) 

> 
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Appendix B 


The CDSS Conflict Probe 


The CDSS . conflict function takes the following parameters: 

s the relative position of the aircraft 
vo the ownship’s velocity 
vi the intruder’s velocity 
D the minimum horizontal distance 
H the minimum vertical distance 

B the the lower bound of the lookahead time (the value 
0 is is implicitly passed in the pseudocode calls) 

T the upper bound of the lookahead time (T < 0 means 
infinite lookahead time) 

It is defined as follows: 

conflict(s,vo,vi,D,H,B,T) : boolean { 
if (T >= 0 AND B >= T) return FALSE 
Vect2 s2 = s.vect2() 

Vect2 vo2 = vo.vect2() 

Vect2 vi2 = vi.vect2() 

if (vo.z ~= vi.z) AND |s.z| < H) { 

return CD2D . cd2d(s . vect2 () , vo2 , vi2 ,D ,B,T) 

} 

vz = vo.z - vi.z 

ml = max(-H - sign(vz) * s.z,B * |vz|) 
if (T < 0) { 

m2 = H - sign(vz) * s.z 
} else { 

m2 = min(H - sign(vz) * s.z, T * |vz|) 

> 

if ( NOT (vo.z ~= vi.z) AND ml < m2) { 

return CD2D . cd2d( | vz I s2 , vo2 , vi2 ,D * |vz|,ml,m2) 

} else { 

return FALSE 

> 

> 

where cd2d is defined as follows 

cd2d(s,vo,vi,D,B,T) : boolean { 
if (T < 0) { 
v = vo - vi 

return almost_horizontal_los (s ,D) OR Delta(s,v,D) > 


0 AND s * v < 0 
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> 

if (B >= T) return FALSE 
v = vo - vi 

return almost_horizontal_los(s+Bv,D) OR omega_vv(s,v,D,B,T) < 0 

and almost_horizontal_los (s ,D) is defined as 

almost_horizontal_los (s ,D) : boolean { 

return NOT (s*s ~= D * D) AND s * s < D * D 

> 

and omega_vv(s,v,D,B,T) is defined as follows: 

omega_vv(s,v,D,B,T) : double { 
if (s*s ~= D * D) AND B ~= 0) { 
return s*v 
} else { 

tau = min(max(B * v * v,-(s * v)),T * v * v) 

> 

return v*v*s*s + (2*tau) * (s*v) + tau*tau - D*D*v*v 

> 

and Delta(s,v,D) and det(s,v) are defined as 

Delta(s,v,D) : double { 

return D*D*V*V- det(s,v) * det(s,v) 

> 

det(s,v) : double { 

return s.x * v.y - s.y * v.x 

> 

In the above functions, the notation ~= is used for approximately equal: equal within 
a specified floating point precision. 
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